Uh, a Maybe.new(...) returning anything but a valid non-Nothing value seems weird to me... nil can be an entirely valid value to return, like the result of a computation that succeeded.

Now Maybe.new() returning Nothing seems perfectly fine though.

@icidasset because nil can represent an actual value in Elixir, Algae.Maybe.new(nil) should return Algae.Maybe.Just{just: nil}. However, if you wanted to add a function like Algae.Maybe.from_nillable/1 or Algae.Maybe.new(value, nothing: nil) to distinguish nil -> Nothing for those that want it, that would work 👍 (Heck, it could even be a list of values)

EDIT: I actually kind of like the nothing: nil idea (above) since the user can define what they want to be taken as Nothing. Then a from_nillable could just be a synonym for new(value, nothing: nil).

Thanks @expede ! I've implemented your idea.

Why not something more like this for new/2?

@spec new(err, [nothing: err]) :: Nothing.t(err)
@spec new(v, [nothing: err]) :: Just.t(v) when v != err

And adjust Just.t and Nothing.t as appropriate as well? (I think that is the right syntax for named typing, might need to make new types though?)

EDIT: Although the above would only work if err and value types are fully distinct, which might be enough for the top level new but would not be for the distinct cases, which is not an issue there anyway as they don't reference each other... Need tests...

@OvermindDL1 Yeah, the automagic type generation could use some work. At the time (way back in the .t days), I was unaware that you could embed types inside types.